Tests en intégration continue

Avant-propos

Pour suivre en live…​

http://bit.ly/jmb-testing

https://jmbruel.github.io/teaching/topics/testingCI.html

Plan

 

Pourquoi tester?

Un exemple concret de test obligatoire : Asciidoctor.org

Un exemple concret de documentation obligatoire : Eclipse

Typologie des tests

JUnit etc.

Application concrète pour ce cours

Pourquoi tester ?

 

A majority of the production failures (77%) can be reproduced by a unit test.


Yuan et al. OSDI 2014
tweet tests
Un tweet récent!
Pour lire l’article en question : https://blog.acolyer.org/2016/10/06/simple-testing-can-prevent-most-critical-failures/amp/

Pour livrer le bon produit

why1
http://www.te52.com/testtalk/2014/08/07/5-reasons-we-need-software-testing/

Ce qui marche pour 1 ne marche pas nécessairement pour 100

why2
http://www.te52.com/testtalk/2014/08/07/5-reasons-we-need-software-testing/

La loi de Murphy

Tout ce qui est susceptible de mal tourner tournera nécessairement mal.


Edward A. Murphy Jr.
why3
http://www.te52.com/testtalk/2014/08/07/5-reasons-we-need-software-testing/

Différents OS ou différents terminaux

why4
http://www.te52.com/testtalk/2014/08/07/5-reasons-we-need-software-testing/

Pour donner le meilleur

why5
http://www.te52.com/testtalk/2014/08/07/5-reasons-we-need-software-testing/

Un exemple concret de test obligatoire

Asciidoctor

Asciidoctor Contribution

danAllen
Autour d’une bière avec Dan Allen, à Denver, Colorado #ILoveMyJob

Submitting a Pull Request

  1. Fork the repository.
  2. Run bundle to install development dependencies.
  3. Create a topic branch
  4. Add tests for your unimplemented feature or bug fix. (See [writing-and-executing-tests])
  5. Run bundle exec rake to run the tests. If your tests pass, return to step 4.
  6. Implement your feature or bug fix.
  7. Run bundle exec rake to run the tests. If your tests fail, return to step 6.
  8. Add documentation for your feature or bug fix.
  9. If your changes are not 100% documented, go back to step 8.
  10. Add, commit, and push your changes.
  11. Submit a pull request.

Un exemple concret de documentation obligatoire

Eclipse

gaelBlondelle
Après un footing avec Gaël Blondel, à Saint-Malo #ILoveMyJob

 

[…​] an Eclipse project is providing extensible frameworks and applications accessible via documented APIs.


Eclipse Development Process

Typologie des tests

 

Vérification

Validation

Le produit est-il bon ?

Le produit est-il le bon ?

Are you building it right?

Are you building the right thing?

Réalisée par le développeur

Réalisée par le testeur

En premier

Après la vérification

https://www.tutorialspoint.com/software_testing/software_testing_quick_guide.htm

JUnit etc.

Quoi tester ?

Les exceptions

@Test (expected = Exception.class)

Le temps d’exécution

@Test(timeout=100)

Uniquement certains environnement

System.getProperty("os.name").contains("Linux")); Attention cette instruction n’est pas une annotation.

S’exécute avant les autres tests (e.g., accès à une base)

@BeforeClass public static void method()

Assertions

fail([message])

On force le test à échouer

assertTrue([message,] condition)

La condition est vraie

assertFalse([message,] condition)

La condition est fausse

assertEquals([message,] attendu, actuel)

Les deux valeurs sont égales

assertNull([message,] object)

Objet nul

assertSame([message,] expected, actual)

Objets identiques (même réf.)

Stratégie de tests

Considérons une fonction int add(int,int); d’une classe myClass.

Cas nominal

Définir le comportement normal de la fonction (sortie normale pour des paramètres corrects).

(source : http://stackoverflow.com/questions/8751553/how-to-write-a-unit-test)
//for normal addition
@Test
public void testAdd1Plus1() {
  int x  = 1 ; int y = 1;
  assertEquals(2, myClass.add(x,y));
}

Cas particuliers

Ajouter des tests pour les cas particuliers :

Cas particuliers

//if you are using 0 as default for null, make sure your class works in that case.
@Test
public void testAdd1Plus1() {
  int y = 1;
  assertEquals(1, myClass.add(null,y));
}

L’ordre des tests

Surtout aucun!!

JUnit assumes that all test methods can be executed in an arbitrary order. Well-written test code should not assume any order, i.e., tests should not depend on other tests.


JUnit manual

Sous Eclipse

Pensez à utiliser le plug-in infinitest.

Et pour les interfaces graphiques?

Exemple de la librairie Robot :

Robot bot = new Robot();
bot.mouseMove(10,10);
bot.mousePress(InputEvent.BUTTON1_MASK);
//add time between press and release or the input event system may
//not think it is a click
try{Thread.sleep(250);}catch(InterruptedException e){}
bot.mouseRelease(InputEvent.BUTTON1_MASK);

 

Exemple du plugin Eclipse swingcoder :

swingTest
https://marketplace.eclipse.org/content/swingcorder

Couverture des tests

Il existe des outils pour aller plus loin :

coverage
http://www.eclemma.org/

Application concrète pour ce cours

De To Be Done à On going

tuleap1

tuleap2

tuleap3

Créer une branche spécifique (si nouvelle feature)

bruel (master) $ git checkout -b US-15378
Switched to a new branch 'US-15378'
bruel (US-15378) $

Ecrire un test qui échoue

Etape 0 : Bien comprendre ce qu’on doit faire

Exemmple : Objectif de la tâche = créer une classe Pile.

Opérations
CréerPile :  -> Pile
estVide   :  Pile ->  Booléen
Empiler   :  Pile * Elément -> Pile
Dépiler   :  Pile -> Pile
Sommet     :  Pile ->  Elément

 

Préconditions
Sommet(p) valide Si et Seulement Si estVide(p) == FAUX
Dépiler(p) valide Si et Seulement Si estVide(p) == FAUX

 

Axiomes
(1) estVide(CréerPile())
(2) estVide(Empiler(p,e)) == FAUX
(3) estVide(Dépiler(Empiler(p,e))) Si et Seulement Si estVide(p)
(4) Sommet(Empiler(p,e)) == e
(5) !estVide(p) => Sommet(Dépiler(Empiler(p,e))) == Sommet(p)

Etape 1 : Ecrire un test simple

import static org.junit.jupiter.api.Assertions.assertEquals;

import org.junit.jupiter.api.Test;

public class PileTest {

		@Test
		public void test_type_new_Pile() throws Exception {
                Pile pile = new Pile() ;

                assertEquals("Pile", pile.getClass().getName(),"new Pile() retourne une Pile");
        }
}

Oups…​

pile2
Oups, JUnit n’est pas dans le path…​

 

pile3
Création rapide de la classe `Pile`

 

pile1
Run as JUnit Tests

Etape 2 : écrire un test qui passe

@Test
public void test_type_empiler() throws Exception {
  Pile pile = new Pile() ;

  assertEquals("Pile", pile.empiler("XXX").getClass().getName(),"empiler(pile,'XXX') retourne une Pile");
}

Erreur de syntaxe

pile4
Erreur de syntaxe

Ajout de la méthode

public class Pile {

	public Object empiler(String string) {
		// TODO Auto-generated method stub
		return this;
	}
}

 

La méthode générée par défaut retourne null ce qui provoque une NullPointerException. Nous avons modifié la méthode en conséquence.

 

public class Pile {

	public Pile empiler(String string) {
		// TODO Auto-generated method stub
		return new Pile();
	}

}

Etape 2 : écrire un test qui échoue

@Test
	public void test_axiome1() {
		  Pile pile = new Pile() ;

		  assertTrue(pile.estVide(pile),"Une nouvelle pile est vide");
		}

Le test échoue (comme souhaité)

	public boolean estVide(Pile pile) {
		// TODO Auto-generated method stub
		return false;
	}

Le test échoue (comme souhaité)

pile7
Passage du test

Ignorer un test

Junit n’exécute que les fonctions qui commencent pas @Test.

Etape 3 : On fait passer le test

public boolean estVide(Pile pile) {
  // Smartly modified by JMB to pass the test!
  return true;
}

Passage du test

pile8
Passage du test

 

Bien sûr le code n’est pas correcte pour l’instant (on s’en rendra compte dès les tests suivants)! Une meilleure solution pourrait être :

public class Pile {
	int count;
  ...
	public boolean estVide(Pile pile) {
		return (count == 0);
	}
}

Essai de merge pour voir si tout le reste marche encore

bruel (US-15378) $ git commit -am "Adding push feature. Tests OK"
[US-15378 78f3242] Adding push feature. Tests OK
 1 file changed, 2 insertions(+), 3 deletions(-)
bruel (US-15378) $ git checkout devs
Switched to branch 'devs'
bruel (devs) $ git merge US-15378

Commit & Push dans devs

bruel (devs) $ git commit -am "..."
...
bruel (devs) $ git push origin devs
...
bruel (devs) $ git branch -D US-15378
Deleted branch US-15378 (was f392a73).

De On going à Review

review
Penser à mettre à jour le tableau de bord

Perles livraison Sprint 1

User Stories / Tasks

Bad Good

badissues

goodissues

Build

Bad Good

Then, you just need to open a cmd here and type "ant run".

badbuild

Lancer la commande "ant build".

goodbuild

Les références absolues!

Position yourself in the project repository (C:\Users\Etudiant\Desktop\Nouveau dossier\MPA2018-Gxxx)


Anonymous

Les instructions qui ne marchent pas…​

Pour lancer l’application, lancer ant Interface


Extrait de la Doc. Utilisateur
$ ant Interface
BUILD FAILED
Target "Interface" does not exist in the project ...

Le build.xml qui manque…​

Pour lancer l’application, lancer ant


Extrait de la Doc. Utilisateur
$ ant
Buildfile: build.xml does not exist!
why3

Statistiques Sprint 1

G1A2

0

G1A3

4

G1A5

1

G1A6

5

G1A7

0

G1B1

21

G1B4

3

G2A1

8

G2B1

0

G2B2

3

G2B3

1

G3A1

77

G3A2

2

G3B1

5

G3B2

5

G3B3

0

G4A1

0

G4A2

0

G4A3

0

Statistiques Sprint 2 (Expected)

Groupe

# classes de test

# tests

Status

1A1

1

~30

buildNOK

1A2

1

1

buildNOK

1B1

1

~10

buildOK

1B2

?

2

buildOK

État des builds et des tests (au 08/10/2016 à 22h40)

 

Groupe

# classes de test

# tests

Status

2A1

0

0

buildOK

2A2

1

~10

buildOK

2B1

2

~10

buildOK

2B2

0

0

buildOK

État des builds et des tests (au 08/10/2016 à 22h40)

The End    (for now)

Quizz

QUESTION
  • Connectez-vous sur : http://www.socrative.com/ (student login)
  • Ou téléchargez l’application pour étudiant socrative2
  • Choisissez la room 44918d67
socrative1